「AWSでのセキュリティ対策全部盛り[初級から中級まで]」をDevelopers.IO 2019 TOKYOで発表しました #cmdevio

こんにちは、臼田です。

みなさん、セキュリティは好きですか？

今回は弊社主催のイベント「Developers.IO 2019 TOKYO」にて「AWSでのセキュリティ対策全部盛り[初級から中級まで]」というタイトルで登壇しましたので、その資料を公開します。

資料

補足とか

発表内容への思い

一番言いたいのは、セキュリティはみんなでやるものだから視野を広く持ってもらいたいし、周りを巻き込んで欲しいということです。

一つの目の前の事象に対して対策を頑張るだけでは意味がなくて、仕組みとして解決したり、組織として解決したり(特に運用)とする必要があります。まあセキュリティに限った話ではないですが。

なので、網羅的にいろんなセキュリティをまとめつつ、これまで気にしてなかった事を気にしていただき、少しでも皆さんの組織が前に進んでもらえたらなーと思ってまとめました。

AWSのメッセージについて

最近下記のメッセージをよく聞きます。

• ゲートからガードレールへ
• みんなBuilders

どちらも非常にいいメッセージなので、僕なりに解釈して伝えてみました。セキュリティに限らず広まって欲しい考え方です。

セキュリティ対策の進め方について

セキュリティ対策って難しいです。完璧もないですし、守るべきものや自分たちのステージに応じて変わります。

なので、クラウドジャーニーやビジネスの成熟度に応じて適切に判断してやっていく必要があります。

例えばDome9は素晴らしいクラウドのコンプライアンス管理製品ですが、小さい環境には宝の持ち腐れです。スケールに合わせて最適なものを選択していきましょう。

そういう面では今回初級から中級と銘打ちましたが、スケールが小さくても初級の一部と中級の一部をいい感じにやっていく必要があると思います。レベル感のまとめ方も難しいなーorz

でもできることなら初級は全部押さえて中級に望んでほしいです。この判断基準を作るのがセキュリティの中で一番難しい気もしますねｗ

自分で判断することに困ったら弊社にご相談くださいｗ

各種フレームワークやコンプライアンスのドキュメントについて

いっぱいあって読むのが大変だと思うのでとりあえず必要なものだけピックアップしました。AWSセキュリティベストプラクティス、Well-Architectedフレームワークはまず見ていただいたほうがいいです。

NISTのCSFは結構重たいのと範囲が広い感じがするので余力があれば。

これらを使う大事な考え方は、「自分たちで基準を作らなくていい」ということです。車輪の再発明は無駄です。グローバルな基準をベースに、自分たちに合わせて少し手を加えるくらいで十分です。

クラウドになると考え方を変える必要があるので、古いチェックシートを捨てるためにも、使える基準をうまく使っていきましょう。

初級: AWSレイヤーのセキュリティ

これはAWSを扱う上で新しい概念なのですべて覚えて実践しましょう。

初級: OS/アプリレイヤーのセキュリティ

これはオンプレミスと同じなので引き続きやりましょう。

ただ、楽になる部分は多いです。使えるサービスを使いましょう。

アプリセキュリティがわからないのであれば徳丸本を。

脆弱性対策はいくつかのレイヤーがありますが、とりあえず診断したことなければ診断しましょう。管理したことなければFutureVuls入れましょう。

WAFも安くて入れやすいのでとりあえずやってもいいと思います。

初級: 運用

運用設計してください

目的が決まれば運用設計は迷うことは少ないはず。

とりあえずAWSだと勝手にメトリクスが収集されて簡単にモニタリングやアラート設定ができるので、最低限やりましょう。

中級: 発見的統制 / インシデントレスポンス

このあたりをガッツリ話したかったですが、網羅的に資料を作ったらあんまりガッツリ話す時間がありませんでした(悲しみ)。2-3時間喋りたい。

一人じゃなくて組織でという要素が強くなってきます。全体の仕組みづくりから考えていくことになりますね。運用設計の範囲内でもあると思います。

いろんな事を検知することになりますが、ここではGuardDutyとConfigの例を上げています。セキュリティという面ではまずはここからですね。

重要なのは受け取ったアラートをどう判断してどう対応するか。GuardDutyなら参考になる公式ドキュメントがあるのでそれベースに考えることと、本当にやばいものが来たときのための準備は事前にしておいてください。

Config Ruleはそれぞれ目的があってルールを選択するはずなので、これも対応方法の準備は困らないはずです。

本当はサービスのモニタリングもここに食い込んできます。そちらは詳しく解説していないですが、おんなじようなスキームでうまいことやってくださいｗ

Sumo Logic使っていただくと可視性は上がるので、余力があれば検討いただくといいと思います。

リクルートテクノロジーズ様の資料は非常にためになります。

中級: GRC(ガバナンス / リスク / コンプライアンス)

直近re:Inforceの話を聞いて特に興味深かったのでこれも掘り下げたかった内容の一つです。

簡単に下記のようにまとめてみましたが、わかりやすいかどうか、的確に捉えているかどうかは正直難しいところですねｗ

• ビジネスに見合う
• リスク管理をして
• 適度に監査をする
• のを状況に合わせてひたすら回す

とりあえずガバナンスやコンプライアンスを考え始めたら、ビジネスとのバランスを意識することが特に重要になってきます。(最初から重要ですけど)

そういう意味でCCoEみたいな組織があれば判断できる軸は持てると思います。個人であーだこーだ出来ないでしょうし。

どのような環境でもとっかかりやすいのが実装難易度も低く具体的な対応方法まで決まっていて、広く浅めなCISベンチマークのAWS Foundatoinsです。まずはこれをinsightwatchを使いながら実践してほしいです。

余力があればDome9や、自前でガリガリConfig Rulesを書いていくという進め方でいいと思います。

最近はAWS Organizations周りのサービスが充実してきていますが、我々からするとまだ使いづらい部分もあり要望をいろいろあげているところでもあります。ハマる環境であれば今からでも導入を検討しつつ、すぐに適用出来ないような環境であれば仕組みを真似しましょう。Organizationsの機能を使わなくてもできることはいっぱいあります。

あとは監査の話。

Compliance as Code (CaC)はとてもおもしろい考え方だと思うので紹介したかった内容です。

冗長で解釈によってブレが大きい文章でのコンプライアンスチェックシートなんて蹴散らして、コードでコンプライアンスを定義してコードで管理しましょう。自動化しやすいのもいいです。

自動化の目的と手段が逆転しないのもいいところだと思います。

全体まとめ

色んな要素のセキュリティに触れましたが、最初に書いたとおりセキュリティは一人でやるものではないですから、この内容をできるだけ多くの人と共有して、前に進んでほしいなーと思います。